1. Field of the Invention
The present invention is directed to the field of accessing an Input/Output (I/O) device, such as a disk volume. It is more particularly directed to improving the performance of computer-implemented I/O operations that are directed to disk drives and that are associated with ported computer applications, such as a database, that operate on the UNIX System Services for the IBM OS/390® (OS/390 UNIX).
2. Description of the Background Art
Typically complex computer applications, such as a database, are ported to a variety of computer systems. The porting process often includes special changes to the application to enable efficient and complete operation of the application on different computer systems. I/O operations are a significant factor in the overall performance of a complex computer application. High-performance computer applications, such as a database, may issue asynchronous, direct disk I/O commands which are not supported on the target system. A “target computer system” as used herein refers to a computer system environment consisting of one or more specific programming languages, the application programming interfaces (APIs) available in the programming languages, and the associated file system or file systems. Therefore, changes to I/O operations may be made during the porting of an application to ensure efficient operation of the application on the computer system. Such a computer system may include the products sold under the trademarks IBM S/390® that includes the IBM OS/390® (OS/390) operating system and associated disk volumes.
Disk volumes are units of data storage that typically include data and the information used to access and manipulate the data. Disk volumes may be used to store a file system and information necessary to manipulate the file system. For example, when implementing database applications that may include disk I/O access commands for operation on the IBM OS/390 that supports UNIX System Services (OS/390 UNIX) the facilities of a hierarchical file system (HFS) may be employed. However, file systems, such as the OS/390 UNIX HFS, may only support queued disk I/O access with minimal I/O caching.
I/O caching is typically managed by either a file system or a disk controller. I/O caching is the process of storing I/O data in computer memory that may be accessed more quickly than the disk device. Therefore, I/O caching may be characterized as temporary storage of data associated with disk I/O requests in computer memory. Complex applications may implement I/O caching for the operation of the application, expecting to bypass the I/O caching facilities of the general-purpose file system.
More particularly general-purpose file systems, such as the OS/390 UNIX HFS, may not have an I/O caching scheme that is tailored to the characteristics of databases. For example, a file system, such as the OS/390 UNIX HFS, may only support queued disk I/O access commands and not direct disk I/O access commands. Queued disk I/O access performs its own I/O caching for proper operation. However, a general-purpose data caching strategy that operates with queued disk I/O access operations may not be optimal for a given application. Therefore an application, such as a database, may perform its own cache management, bypass the file system, and directly access information on a disk. For example, a database may achieve better I/O access performance by using direct I/O access features, available as high-level computer language APIs on many UNIX platforms, in place of queued disk I/O access operations. Also, a database may improve I/O access by managing I/O caching of data instead of relying on the I/O caching scheme of the general-purpose file system.
Queued disk I/O access commands may operate most efficiently with sequential I/O access operations and not random I/O access operations. Highly complex software applications, such as a database, often issue random I/O access requests and the performance of the complex software applications may suffer if I/O requests are serviced by queued disk I/O, which may be designed to optimize sequential rather than random access operations. Therefore, high-performance computer applications, such as a database, may issue direct disk I/O commands that can efficiently process random I/O requests, when accessing disk volumes. If the application being ported is written using asynchronous, direct I/O APIs not supported on the target computer system, which is the case with the OS/390 UNIX C Library and the OS/390 HFS, the performance of the ported application may suffer because those direct I/O commands must be rewritten as queued I/O commands. This may be the case if the computer system is optimized for queued I/O. Those skilled in the art will appreciate the use of sequential I/O and random I/O operations with respect to disk I/O access.
A general-purpose file system may only be able to service I/O requests synchronously. Synchronous I/O operations wait for confirmation that the I/O disk access command has completed before executing another disk I/O access command. The delay in proceeding with subsequent disk I/O access commands impacts application I/O access performance. Asynchronous I/O access commands typically enable other computer operations to proceed that would otherwise wait until the I/O operation successfully completes. This allows I/O operations and other computer operations to overlap and proceed in an asynchronous fashion. Consequently, asynchronous I/O operations perform more efficiently than synchronous disk I/O operations for certain high performance applications, such as a database. Therefore, database software applications suffer performance penalties if they are constrained to use high-level language APIs that do not support asynchronous I/O operations, such as the OS/390 UNIX C Run-time APIs.
In summary, complex applications, such as databases, often include specialized features that ensure that I/O requests are properly sequenced. Typically, these features operate via direct disk I/O operations that facilitate servicing random I/O requests. Therefore, the application code may bypass the I/O caching features of the general-purpose file system in favor of the specialized I/O caching features of the application. When porting the application, limitations of the target computer system may impact the performance of the application. For instance, if a particular UNIX file system supports queued I/O access commands directed to disk volumes and not direct I/O access commands, unacceptably poor I/O access performance for the application may result. Also, if a file system supports synchronous I/O access to disk volumes and not asynchronous I/O access, poor performance for the application may result. Further, a general-purpose file system I/O caching scheme that is optimized for sequential I/O requests may result in poor performance for an application, such as a database, that issues many random I/O requests.
From the foregoing it will be apparent that there is a need to improve disk I/O performance when porting a complex application that uses asynchronous, direct I/O commands to a target computer system that does not support those commands.